prevent user.uuid from being regenerated on each operation by reading it from the DB by DaanHoogland · Pull Request #12632 · apache/cloudstack

DaanHoogland · 2026-02-11T17:11:01Z

Description

This PR implements the reporters suggestion as requested...

Fixes: #12612

Types of changes

Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change which adds functionality)
Bug fix (non-breaking change which fixes an issue)
Enhancement (improves an existing feature and functionality)
Cleanup (Code refactoring and cleanup, that may add test cases)
Build/CI
Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Major
Minor

Bug Severity

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

codecov · 2026-02-11T17:16:18Z

Codecov Report

❌ Patch coverage is 24.13793% with 44 lines in your changes missing coverage. Please review.
✅ Project coverage is 16.25%. Comparing base (34f6f41) to head (0c787b9).
⚠️ Report is 10 commits behind head on 4.20.

Files with missing lines	Patch %	Lines
...c/main/java/com/cloud/user/AccountManagerImpl.java	23.63%	41 Missing and 1 partial ⚠️
...c/main/java/com/cloud/user/dao/AccountDaoImpl.java	0.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               4.20   #12632      +/-   ##
============================================
- Coverage     16.25%   16.25%   -0.01%     
- Complexity    13421    13433      +12     
============================================
  Files          5662     5662              
  Lines        500141   500580     +439     
  Branches      60728    60969     +241     
============================================
+ Hits          81299    81365      +66     
- Misses       409759   410128     +369     
- Partials       9083     9087       +4

Flag	Coverage Δ
uitests	`4.15% <ø> (ø)`
unittests	`17.10% <24.13%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copilot

Pull request overview

This PR addresses issue #12612 where API-key authentication could yield a different (random) user UUID per request, by ensuring the user’s UUID is read from the database and propagated into the User object used in auth/context.

Changes:

Update the FIND_USER_ACCOUNT_BY_API_KEY query and result mapping to include and set u.uuid.
Adjust UserVO(long id) initialization to delegate to the no-arg constructor.
Extend the com.cloud.user.User interface to include setUuid(String).

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
engine/schema/src/main/java/com/cloud/user/dao/AccountDaoImpl.java	Adds UUID to the API-key lookup query and maps it into the `User` instance.
engine/schema/src/main/java/com/cloud/user/UserVO.java	Changes the `UserVO(long id)` constructor to call `this()` before setting `id`.
api/src/main/java/com/cloud/user/User.java	Adds `setUuid(String uuid)` to the `User` interface.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

engine/schema/src/main/java/com/cloud/user/dao/AccountDaoImpl.java

api/src/main/java/com/cloud/user/User.java

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

abh1sar

code LGTM

sureshanaparti

clgtm

weizhouapache · 2026-02-12T07:32:15Z

@DaanHoogland
can we use this method UserAccountDao.getUserByApiKey instead ?

DaanHoogland · 2026-02-12T08:32:45Z

@DaanHoogland can we use this method UserAccountDao.getUserByApiKey instead ?

no doubt, but can you be more specific? Do you mean, bypass findUserAccountByApiKey altogether? Or call UserAccountDao.getUserByApiKey from within it. I am sure you mean to suggest a cleanup refactor, but that is as far as my understanding goes.

Note findUserAccountByApiKey is called in three places. Happy to make this PR more elaborate.

weizhouapache · 2026-02-12T10:01:22Z

@DaanHoogland can we use this method UserAccountDao.getUserByApiKey instead ?

no doubt, but can you be more specific? Do you mean, bypass findUserAccountByApiKey altogether? Or call UserAccountDao.getUserByApiKey from within it. I am sure you mean to suggest a cleanup refactor, but that is as far as my understanding goes.

Note findUserAccountByApiKey is called in three places. Happy to make this PR more elaborate.

@DaanHoogland
I had a quick look, I think remove the method accountDao.findUserAccountByApiKey(apiKey), and use this method instead

--- a/server/src/main/java/com/cloud/user/AccountManagerImpl.java
+++ b/server/src/main/java/com/cloud/user/AccountManagerImpl.java
@@ -3051,7 +3051,9 @@ public class AccountManagerImpl extends ManagerBase implements AccountManager, M
 
     @Override
     public Pair<User, Account> findUserByApiKey(String apiKey) {
-        return _accountDao.findUserAccountByApiKey(apiKey);
+        UserAccount userAccount = _userAccountDao.getUserByApiKey(apiKey);
+        // TODO: get User and Account from userAccount or from DB
+        return new Pair<>(user, account);
     }
 
     @Override

…ountDao.getUserByApiKey(encodedKey)`

DaanHoogland · 2026-02-12T12:52:16Z

@DaanHoogland can we use this method UserAccountDao.getUserByApiKey instead ?

no doubt, but can you be more specific? Do you mean, bypass findUserAccountByApiKey altogether? Or call UserAccountDao.getUserByApiKey from within it. I am sure you mean to suggest a cleanup refactor, but that is as far as my understanding goes.
Note findUserAccountByApiKey is called in three places. Happy to make this PR more elaborate.

@DaanHoogland I had a quick look, I think remove the method accountDao.findUserAccountByApiKey(apiKey), and use this method instead
--- a/server/src/main/java/com/cloud/user/AccountManagerImpl.java
+++ b/server/src/main/java/com/cloud/user/AccountManagerImpl.java
@@ -3051,7 +3051,9 @@ public class AccountManagerImpl extends ManagerBase implements AccountManager, M
 
     @Override
     public Pair<User, Account> findUserByApiKey(String apiKey) {
-        return _accountDao.findUserAccountByApiKey(apiKey);
+        UserAccount userAccount = _userAccountDao.getUserByApiKey(apiKey);
+        // TODO: get User and Account from userAccount or from DB
+        return new Pair<>(user, account);
     }
 
     @Override

ok, gave it a stab, AccountDoa.findUserAccountByApiKey(apiKey) could be removed like this. Some test cleanup and interface needed.

weizhouapache · 2026-02-12T14:19:35Z

ok, gave it a stab, AccountDoa.findUserAccountByApiKey(apiKey) could be removed like this. Some test cleanup and interface needed.

good, look forward to your more changes

sonarqubecloud · 2026-02-13T14:56:56Z

Quality Gate failed

Failed conditions
10.1% Coverage on New Code (required ≥ 40%)

See analysis details on SonarQube Cloud

DaanHoogland · 2026-02-13T14:58:03Z

@blueorangutan package

blueorangutan · 2026-02-13T15:00:04Z

@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

blueorangutan · 2026-02-13T15:54:58Z

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16831

DaanHoogland · 2026-02-17T13:31:05Z

@blueorangutan test

blueorangutan · 2026-02-17T13:32:04Z

@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

blueorangutan · 2026-02-18T04:35:52Z

[SF] Trillian test result (tid-15494)
Environment: kvm-ol8 (x2), zone: Advanced Networking with Mgmt server ol8
Total time taken: 51412 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr12632-t15494-kvm-ol8.zip
Smoke tests completed. 140 look OK, 1 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File
test_01_isolate_network_FW_PF_default_routes_egress_true	`Failure`	107.95	test_routers_network_ops.py

weizhouapache

code lgtm

DaanHoogland · 2026-02-20T08:53:52Z

@blueorangutan test keepEnv

abh1sar · 2026-02-20T08:53:59Z

@blueorangutan test keepEnv

blueorangutan · 2026-02-20T08:56:06Z

@abh1sar a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

blueorangutan · 2026-02-21T02:12:55Z

[SF] Trillian test result (tid-15504)
Environment: kvm-ol8 (x2), zone: Advanced Networking with Mgmt server ol8
Total time taken: 59095 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr12632-t15504-kvm-ol8.zip
Smoke tests completed. 141 look OK, 0 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File

RosiKyu

LGTM

#	Test Case	Method	Status
TC1	User UUID is consistent across repeated API-key authenticated requests and matches DB value	curl + mysql	PASS
TC2	Normal API key authentication works correctly (no regression)	curl	PASS

Result: 2/2 PASS

Verified that API key authentication now returns the correct user UUID from the database consistently across multiple requests, fixing the random UUID generation issue described in #12612. No regressions observed in normal API key authentication flow.

TC1: User UUID is consistent across repeated API-key authenticated requests

Objective Verify that API key authentication returns the same (correct) user UUID on every request, instead of generating a random UUID each time (the original bug described in #12612).

Test Steps

As RootAdmin, create a regular User account uuidtest
Register API keys for the user
Confirm the user's UUID in the database: SELECT id, uuid, username FROM cloud.user WHERE username='uuidtest';
Using curl with API key signature authentication, call an admin-only API (listHosts) 3 times as the uuidtest user
Compare the UUID in each error response to each other and to the DB value

Expected Result: All 3 error responses should contain the same user UUID, and it should match the UUID stored in the database (0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1).

Actual Result: All 3 responses returned the identical UUID 0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1, matching the database value.

Test Evidence:

# Database UUID:
mysql> SELECT id, uuid, username FROM cloud.user WHERE username='uuidtest';
+----+--------------------------------------+----------+
| id | uuid                                 | username |
+----+--------------------------------------+----------+
|  5 | 0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1 | uuidtest |
+----+--------------------------------------+----------+

# API responses (3 consecutive requests):
=== Request 1 ===
"errortext": "The API [listHosts] does not exist or is not available for the account for user id [0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1]."
=== Request 2 ===
"errortext": "The API [listHosts] does not exist or is not available for the account for user id [0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1]."
=== Request 3 ===
"errortext": "The API [listHosts] does not exist or is not available for the account for user id [0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1]."

TC2: Normal API key authentication works correctly (no regression)

Objective Verify that API key authentication continues to work for permitted API calls after the refactoring, and that the returned user UUID matches the database value.

Test Steps

Using the same uuidtest user with API key authentication
Call a permitted API (listAccounts) via curl with API key signature
Verify the call succeeds and the user UUID in the response matches the database value

Expected Result: The API call should succeed (HTTP 200, valid response) and the user id field in the response should match the database UUID (0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1).

Actual Result: The listAccounts API returned successfully with the uuidtest account details. The user id in the response is 0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1, matching the database value.

Test Evidence:

# API response (successful listAccounts via API key auth):
{
    "listaccountsresponse": {
        "count": 1,
        "account": [{
            "id": "1212ec3c-c3a4-4b21-8429-3966a10a82b0",
            "name": "uuidtest",
            "user": [{
                "id": "0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1",
                "username": "uuidtest",
                "apikey": "2pzbGDWWJW66tSOcjwJx1_FP6HxO971EJ4Wkcp0eQhy8iIMiXndWowsALbVLi5kAmN0dvRNorTCkMXY_Usl6SQ",
                ...
            }]
        }]
    }
}

# Database UUID (confirmed in TC1):
0d5fe11a-ea49-4ea7-9bc6-6b3ede0af4d1 MATCH

weizhouapache · 2026-02-23T10:05:09Z

thanks @RosiKyu

@DaanHoogland
I believe this is ready for merge.
can you add more info in the commit title or description if possible ?

read user.uuid from DB

f6e4fa7

boring-cyborg bot added the component:api label Feb 11, 2026

DaanHoogland added this to the 4.20.3 milestone Feb 11, 2026

DaanHoogland linked an issue Feb 11, 2026 that may be closed by this pull request

AccountDaoImpl.findUserAccountByApiKey() generates random UUID instead of reading from database #12612

Closed

DaanHoogland requested review from abh1sar and Copilot and removed request for abh1sar February 11, 2026 17:11

Copilot started reviewing on behalf of DaanHoogland February 11, 2026 17:12 View session

DaanHoogland requested a review from weizhouapache February 11, 2026 17:12

Copilot AI reviewed Feb 11, 2026

View reviewed changes

engine/schema/src/main/java/com/cloud/user/dao/AccountDaoImpl.java Outdated Show resolved Hide resolved

api/src/main/java/com/cloud/user/User.java Outdated Show resolved Hide resolved

DaanHoogland and others added 2 commits February 11, 2026 18:23

Apply suggestion from @Copilot

7c39933

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

cleanup

9f0443a

abh1sar approved these changes Feb 12, 2026

View reviewed changes

sureshanaparti approved these changes Feb 12, 2026

View reviewed changes

Daan Hoogland added 2 commits February 12, 2026 13:40

replace some AccountDoa.findUserAccountByApiKey(apiKey) by `UserAcc…

305a0a8

…ountDao.getUserByApiKey(encodedKey)`

phase out AccountDoa.findUserAccountByApiKey(apiKey)

8029ef3

cleanup

0c787b9

DaanHoogland mentioned this pull request Feb 13, 2026

[4.20] Fix account deletion blocked by deleted project admin mappings #12615

Open

2 tasks

abh1sar removed this from the 4.20.3 milestone Feb 16, 2026

abh1sar added this to the 4.20.4 milestone Feb 16, 2026

RosiKyu self-assigned this Feb 19, 2026

RosiKyu added the ready-for-testing label Feb 19, 2026

weizhouapache approved these changes Feb 19, 2026

View reviewed changes

RosiKyu added status:testing and removed ready-for-testing labels Feb 23, 2026

RosiKyu approved these changes Feb 23, 2026

View reviewed changes

RosiKyu added status:tested status:ready-for-merge and removed status:testing labels Feb 23, 2026

DaanHoogland changed the title ~~read user.uuid from DB~~ prevent user.uuid from being regenerated on each operation by reading it from the DB Feb 23, 2026

DaanHoogland merged commit da7ac80 into 4.20 Feb 23, 2026
65 of 67 checks passed

DaanHoogland deleted the ghi12612-userUuidPreservation branch February 23, 2026 10:12

DaanHoogland modified the milestones: 4.20.4, 4.20.3 Feb 23, 2026

DaanHoogland mentioned this pull request Feb 23, 2026

AccountDaoImpl.findUserAccountByApiKey() generates random UUID instead of reading from database #12612

Closed

RosiKyu removed the status:ready-for-merge label Feb 23, 2026

Comments

Conversation

DaanHoogland commented Feb 11, 2026

Description

Types of changes

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Bug Severity

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

Uh oh!

codecov bot commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

abh1sar left a comment

Choose a reason for hiding this comment

Uh oh!

sureshanaparti left a comment

Choose a reason for hiding this comment

Uh oh!

weizhouapache commented Feb 12, 2026

Uh oh!

DaanHoogland commented Feb 12, 2026

Uh oh!

weizhouapache commented Feb 12, 2026

Uh oh!

DaanHoogland commented Feb 12, 2026

Uh oh!

weizhouapache commented Feb 12, 2026

Uh oh!

sonarqubecloud bot commented Feb 13, 2026

Quality Gate failed

Uh oh!

DaanHoogland commented Feb 13, 2026

Uh oh!

blueorangutan commented Feb 13, 2026

Uh oh!

blueorangutan commented Feb 13, 2026

Uh oh!

DaanHoogland commented Feb 17, 2026

Uh oh!

blueorangutan commented Feb 17, 2026

Uh oh!

blueorangutan commented Feb 18, 2026

Uh oh!

weizhouapache left a comment

Choose a reason for hiding this comment

Uh oh!

DaanHoogland commented Feb 20, 2026

Uh oh!

abh1sar commented Feb 20, 2026

Uh oh!

blueorangutan commented Feb 20, 2026

Uh oh!

blueorangutan commented Feb 21, 2026

Uh oh!

RosiKyu left a comment

Choose a reason for hiding this comment

LGTM

TC1: User UUID is consistent across repeated API-key authenticated requests

TC2: Normal API key authentication works correctly (no regression)

Uh oh!

weizhouapache commented Feb 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

codecov bot commented Feb 11, 2026 •

edited

Loading